Safe and secure program execution framework

ABSTRACT

A system and method is provided here that can make sure that the instruction sets executing on a computer are certified and secure. The system and method further facilitates a generic way to intercept instruction loading process to inspect loaded code segment 1 st  before computer get a chance to execute them. 
     Further, a profiling component can monitor all executing process running in a system and profile behavior of the program. If the behavior is suspicious, established by a set of predefined rules, the profiler can take necessary action to notify system administrator and suspend or terminate execution of the program.

TECHNICAL FIELD

The present invention relates to program loading, program execution,monitoring and verifying loaded instruction module inside a program,computer security and more specifically making sure that the instructionset loaded inside a program is secure and safe.

BACKGROUND OF THE INVENTION

In modern computing environment security is one of the most importantfactors. It should be highest priority to make sure that a computeralways executes safe computer instructions to maintain privacy andsecurity. A computer will be connected to the network, and there will beoutside attacker who will try to destabilize computing environment orsteal valuable information stored somewhere in the network. The mostcommon way to achieve those things is to find some exploitable hole andthen inject some computer instruction that can be executed internally.

Theoretically, there will be always security vulnerability, and therewill be a possibility that someone will be trying to push some bad stuffexploiting that vulnerability. Then it's up to the user/computer to dealwith those bad stuffs. Most of the users are not expert and for examplethey can easily double click on an email attachment to welcome those badstuffs. Or sometimes OS or some running program automatically welcomethose bad stuff because of exploitable security hole in thoseapplication or OS.

Antivirus program is kind of passive protection. It can scan files forpossible infection; it can scan memory for the similar thing. Thosescanning process is assisted by some preset signatures to flag thatmemory or files are infected. However, there is no easy way to makeconventional anti-virus application smart enough so that it candetermine any newly written future virus. Firewall application typicallyblocks request from unknown or suspicious sources. However they can'tblock legitimate request. For example user need to browse internet, sendemail, use other network resources communicate other computers in thenetwork. Sometimes some unintentional or ignorant act might causeproblems. An email attachment might contain bad instructions. Or anemployee might download a file from the internet and execute themlocally that can eventually install bad stuff on computer. Therefore,those virus or firewall based protection are not good enough to identifynew innovative future attack. In this invention, we present a novelapproach that can identify bad instructions module in the system at thetime they get loaded in the system and do the verification using aunique easily deployable authentication framework. The proposedinvention can make sure that the instructions running in the system aresafe.

Local Authentication Framework can acquire knowledge from the globalAuthentication Framework (AF). AF already knows what modules areavailable that can be safely executed on local system. The knowledgebase of the framework can be adaptive; continuously learn about newmodules relating new products, updates available to the users, newfindings on a module or products. FA helps applying the knowledgeacquired from the global FA to end user system to make computing systemmore secure and safe. The Authentication Framework helps administratorto set some rules or policy to define certified instruction set/modulesto run across computers. That makes the network environment moreefficient and manageable because administrator can control what can berun in the system and what can't. If some certified instruction modulebecomes vulnerable to attack, administrator can make the moduleuncertified and update its central database with a new certified module(for example available from vendor). In that case all computers in thenetwork can pickup the certified module quickly and automatically. Alsothis can help administrator to manage licensed product. Administratorcan certify program modules based on user account, Machine account. Thatway, administrator can centrally manage that no unlicensed product arein use in the network.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the present invention inorder to provide some basic details of some aspects of the invention.This summary is not an extensive overview of the invention. It is notintended to identify key/critical elements of the invention or to reducethe scope of the invention. Its sole purpose is to present some conceptof the invention in a simplified form; more detailed description ispresented later.

The present invention provides a system and method that can interceptand manipulate program/instruction loading process, verify that thoseloaded instructions are certified and safe before computer actuallyexecute them. Also it can replace any uncertified instructionset/modules with compatible certified instruction/modules to deploy anysecurity patch quickly in a more manageable way.

When OS load a program, it typically allocates some memory and loadrequired instructions in modules the program depends on. A callinterceptor will intercept the loading process and figure out whichmodules Operating system loader is trying to load. Then for each programmodule it will check with authentication framework to verify that themodule is certified safe to load and can be loaded based on givencredentials. The credentials might include, user name, machine account,module information (time stamp, vendor info, size, checksum etc).Authentication Framework resolve the module load info using a resolvingmechanism and generate an action policy record something like givenmodule is unsafe to load, given module need to be replaced with aupdated module etc. Then deployment module takes necessary action toimplement the action record. If needed, deployment module can replacethe local module with a certified module and load the certified oneinstead.

Authentication Framework can work in the similar way DNS frameworkworks. The framework can maintain some local table with some informationrelated to module info and policy local to the system. Whenever requiredit can contact a remote authentication server to retrieve moreinformation when local table don't have enough information. Initial datain the local table can be update by contacting remote server andinspecting local system. A module can be uniquely identified bycombination of its name, size, checksum, vendor info etc. Each modulecan have some attributes entry specifying which user/machine can executethem. A remote authentication server can contact additional top levelserver in the framework to resolve authentication request if needed.

Authentication framework is an important independent piece that willfacilitate to catalog all publicly available instruction modules.Instruction modules is a place holder of computer instruction that cancontrol the execution of program that eventually dictate end result auser gets from computer. DLL, EXE, web scripts, java class, etc can beconsidered as program modules. Catalog containing module informationwill be updated regularly as new program modules becomes available forpublic uses through different trusted channels including retail productswed downloads etc. It is also possible to catalog modules within certainscope. For example in corporate environment, corporation might haveproprietary program modules that need to be authenticated within theirnetwork only So the authentication server serving the private networkcan have catalog containing module information local to the network.

The framework can be implemented in many ways in combination of few coreelements:

-   -   a) Clients that need authentication service    -   b) Servers handling those authentication requests    -   c) A set of protocols to establish communication between clients        and servers in secure way.    -   d) Optimization modules that can cache authentication requests        in different stages.    -   e) Catalog service that will catalog available modules that will        be used by the authentication servers.    -   f) A way to resolve authentication request the way internet name        get resolved.

Another aspect of this invention would be to apply module verificationprocess in managing program licensing. Every time a product getslaunched, it will check with the table if the loaded module iscertified. An administrator can set policy to certify module based onuser or machine account and possibly a licensing period. Administratorcan also specify action to be taken if users try to load a module withexpired license, uncertified, etc. So the capability can be enhanced inmany ways.

This is analogous to securing or protecting human body system wherehuman body is always vulnerable to attack from internal or externalmicro organism like bacteria or virus. Constant screening diagnosis andsome built-in antibody can reduce the scope of those attacks and reduceprevalence of infection from micro organism significantly. Also there isa central authority like FDA that can certify what kind offood/preventive medicine can be safe for public health by setting somestandards. Analogous to the system a) monitoring process modules workslike screening process a) intercepting module kind ofantibody/preventive medicine c) Authentication Framework settingstandards what can be executed like FDA does and d) deployment moduleact like caring facility to make computing system more secure and safeand less vulnerable.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a Block diagram of call Intercept processor, AuthenticationFramework and Deployment module

FIG. 2 is a flow diagram of how active call Intercept processor works.

FIG. 3 is a flow diagram of how passive call Intercept processor works.

FIG. 4 is a flow diagram how Authentication framework works.

FIG. 5 illustrates how deployment module work

FIG. 6 Different Framework Components

DETAIL DESCRIPTION OF THE INVENTION

The present invention is now described with reference to the drawings.In the following description, for purpose of explanation, numerousspecific details are set forth in order to provide a throughunderstanding of the present invention.

FIG. 1 shows block diagram of different components in a typicalenvironment. Block 120 is computing system representing any computersystem with any hardware configuration running any operating system likeWindows UNIX etc. User can run their application like web application,word processor, database application etc the on the system. Block 110shows user interaction commands; they way user might initiate runningapplication on the system. User interaction might be as simple asclicking on an icon on computer, or activating an application remotelyor running an application at some preset schedule. Block 2000 is diskstorage containing necessary persistent information different componentsmight need. 300 is the component responsible to check which modules isloaded or getting loaded in the system. 300 might be embedded in anyrunning process on the computing system 120. 300 might monitor routinelywhat are the instruction modules already loaded on 120. For examplewhile running an application say hello.exe, it might load more modulessay foo.dll and goo.dll. User might issue command to run hello.exe on120. Interceptor will report the event actively when hello.exe foo.dlland goo.dll get loaded and will initiate some process to complete beforehello.exe gets executed on the system. Interceptor will report passivelythat hello.exe is running on the system and it has loaded componentsgoo.dll and foo.dll. System administrator can configure how interceptorshould work.

600 is the infrastructure in combination of a set of protocols,connected servers where a request from 300 may be served. 300 mightissue some query if hello.exe foo.dll and goo.dll is recognizedcomponents that can be safely run on the system. It might receive somefeedback like the module is not safe to run on the system. 600 willdefine how a request should be formed and constituted. 600 would definehow the request should be delivered. It would define the response aswell. A computing system can be part of framework that can work as aremote server serving a set of queries. Those servers will have accessto some catalog containing information of modules a computing systemmight use. Catalog can be used to build system policy 2100 suitable fora computing system or a private network. Another component in theframework might dynamically update catalog or system policy whenever newmodules or information associated new modules are available or newinformation on a module is found or system need to be configured.

2100 constitute system policy which is a table containing collection ofinformation of available modules relevant to the scope of the framework.System policy can be constituted from a catalog of modules that can berelevant in a network. For example in a private network, there arecertain numbers of modules only used in the private network. A systempolicy can be developed based on those modules and network needs.

820 is deployment modules that can make sure a policy is properlyfollowed. System policy might define “foo.dll with some signature “S”can safely run in the network but foo.dll with signature Y can't run.

2200 is the optional report module that basically compiles informationon any violation of system policy in the network or system and report toadministrator.

FIG. 2 shows how an active interceptor can be implemented in a typicalcomputing environment and how it would work. In FIG. 2, module 100 issuecommand to launch application. Say user issue a command to lunch anapplication hello.exe. 200 is part of the OS that interpret the usercommand and initiate launch sequence. Launch sequence typically covers,allocating memory, reading hello.exe from disk, load all the moduleshello.exe depends on etc. module 300 is the key component which iscapable of intercepting all the call OS uses to load all the modules.Those calls might be mapping hello.exe into memory along with itsdependent modules. Dependent modules mean hello.exe needs more modulesit has dependency on to be loaded as well. Thus interceptor takes a1^(st) look at all modules before OS get a chance to use them forhello.exe. Thus interceptor knows which module is about to get loaded(say foo.dll) for hello.exe program. Then it extracts some informationfrom foo.dll and makes a request to authentication framework module 600asking “a program is about to load foo.dll with signature X “what shouldI do”. Signature X might be some unique ID that can uniquely identifythe module. Every component in the framework will understand thesignature and what it correspond to. Framework will resolve the requestand send the caller some feed back like “the module is safe to load” or“the module is completely unknown” or the “module is marked as risk tothe system” or “the module need to be patched” or any combinations. Onceinterceptor receives the result from the framework, it can allow the OScall to succeed to continue hello.exe loading process. Or it can deliverthe result to deployment module 800 to implement the result returnedfrom the framework to make sure loading the program with dependentcomponents doesn't violate any local system policy. Deployment modulewill analyze the result and check with local system policy (if any) todetermine action items. In some case the action might be to replace themodule with a newer or different version of the module, sometimes delaythe execution to comply with the license etc. If deployment module failsto resolve the issue raised by local policy or framework it can requestinterceptor to terminate loading sequence and ask report module 1000 tonotify user/administrators with appropriate information explaining whathappened.

FIG. 3 shows how a passive interceptor can be implemented in a typicalcomputing environment and how it would work. Contrary to activeinterceptor passive interceptor is kind of monitoring process that lookat what module get loaded in a program and verify if those module arethe right one. In FIG. 3 module 300 start inspecting all program loadedin the system. It walks through each module M loaded in a process P,then it extracts some information from module M to construct someidentification signature S. The signature can be generated computinghash on the module, taking module creation time stamp, vendors whocreated the module if available etc. The signature must be unique andwell understood by the different components in the framework identifyingthe same module. Interceptor then send a request to authenticationframework seeking if any action need to be performed with the module Mwith signature S. Authentication framework resolve the request and sendthe result to interceptor. The result might say “the module is notrecognized” or “the module need to be replaced by a newer version” etc.Interceptor then contact deployment module if any action need to betaken to comply the AF result and system policy.

FIG. 4 shows how an authentication framework can be implemented in atypical computing environment and how it would work. Authenticationframework is the core component that is the central nervous system ofthis authentication mechanism. This can be implemented as a module in asingle computer system with some local scope or it might be implementedwith a client module in all computer system with the support of servermodules deployed in the network where client module ca talk to servermodule to resolve a request. A server might contact additional server toresolve the request if needed. In the FIG. 4, module 300, theinterceptor collect information from a module say M. The framework willdefine a set of protocols so that different servers and client's modulecan interact with each other. 300 will construct a request for themodule M using some functionality provided by the client frameworkmodule. It then sends the request to that framework which is the clientframework module in the local system. Local client framework module willmaintain a local table that will contain information about local policy,local user info, local execution environment, local cache etc. Toresolve the request for module M, it search local table to find a match,if match is not found it then contact a remote framework serverrequesting to resolve the request if needed. The remote server mightcontact additional server to resolve the request if needed. Localframework module might scan the local system initially to populate thelocal table or contact a remote server to initialize its local table. Anadministrator can configure how the initial state can be populated.Remote server or servers can be connected to some DB containing moduleinformation. Another process will periodically update the DB with themost up-to-date information.

FIG. 5 shows how a deployment module can be implemented in a typicalcomputing environment and how it would work. This implement any actionitems computed from local policy and framework result. Local policy isthe policy set by local administrator for the local system. Local policymight say “don't allow execution of any module not authenticated by theframework” or “if newer version of module foo.dll is available” alwaysuse that module. Or “if user U is launching hello.exe don't allow that”Those policy becomes part of Local framework client module.Administrator can also set policy only applicable to private network.When interceptor issue a request to authentication framework “Can user Uexecute hello.exe with signature S” Local framework module might checkits local table to see if the request can be resolved. Say it find somelocal policy stating “User U can execute hello.exe if signature isvalid.” Then it checks again if local table contain the signatureidentifying hello.exe. If signature is not found it contacts remoteserver. Remote server than check with its DB and resolve the request as“hello.exe with the signature has severe security hole, it must bereplaced with a newer version.” When deployment module receives theresult, it might contact some server (may be another server part offramework) to copy newer version of hello.exe. The authenticationframework might not find the signature. In that scenario, the file mightbe infected by some virus or some temperament might have caused tochange the signature. Deployment module might try to fix it the way anantivirus application would have tried to disinfect the module. It mightalso try to replace the module if the original signature can beretrieved in some way. File location, vendor info, date might lead to aunique combination that can be used to look up original signature. Onceoriginal signature is found another database can be searched for theoriginal file to replace.

The Authentication framework can be used for licensing management.Administrator can set some policy applicable to local system or within anetwork. The policy can be something like “hello.exe can be launched onpredefined number of computer in the network”. Or “hello.exe can belaunched within a predefined time on system with a user account in agiven set. When hello.exe gets launched on a system, interceptor in AFintercept modules loaded by the application. The intercepted modulesthen checked against AF database along with the user info.Authentication Framework can check with local policy and return “timehas expired” or “more instance of the module can't be launched” or Theuser doesn't have license to run this, or user need to pay subscription1^(st).

FIG. 6 shows different components of AF with more examples. In the FIG.6, Remote Authentication Framework Server (RAFS) is the server havingaccess to database (DB) containing module information. RAFS might bededicated to a private network or can be part of Global network. Networkadministrator can set policy which will be part of DB accessed fromRAFS.

When a user set up a system S it needs to have Local AuthenticationFramework client (LAFC) module AF. AF will initialize its local databaseD with at least one table Tlm to contain module information. Tlm willhave associated version number that would define how a record isconstituted for a module. <Module Signature, Module name, ModuleCreation Date, Vendor name> can represent individual field or column oftable Tlm. A different table version can have different set ofattributes. Module Signature is a unique ID that uniquely represents amodule. Signature is computed applying an algorithm A(i) over a module.Different version of A will represent different Signature for the samemodule. For example Module signature can be MD5 hash computed over themodule taking whole or part of the module. The version of the algorithmcan dictate if MD5 or other algorithm was used over whole or part of amodule.

The administrator can configure the LAFC to trust all the modules atgiven time and initialize the Table. At that point, LAFC can scan thesystem to populate the Tlm. Administrator can configure which remoteAuthentication Framework server (RAFS) it needs to contact when needed.This AF configuration can be done remotely and automatically as well.Administrator can set Local system policy that will sit in another tableTlp in D. Administrator can set any kind of policy to populate Tlp andAF can interpret. LAFC can contact remote Authentication FrameworkServer to sync-up its Table Tlm and Tlp if needed.

When user attempt to run an application on system S, LAFC interceptorintercepts modules loaded by the application. Then consult with AF DBand take necessary action. User can simply download an application fromthe internet. While attempting to run the downloaded application, LAFCinterceptor will intercept the event, compute data including signatureto identify the module, search for the module in local DB, finds no hitin its local DB. It then contact remote AF server. Few scenarios canhappen:

-   -   1. The remote AF server can have preset strict policy not to        allow any new module in the network with full user account        privilege. In that can user can try to run the app with less        privilege system account that has restricted user access remote        AF server can allow. AF can deny running any unrecognized module        without network administrator privilege.    -   2. Remote Authentication doesn't find any hit in its DB, and        preset policy allows running any authorized module. It then        contact more remote AF server to check if the module can be        authenticated.    -   3. RAFS doesn't find its module signature in its DB. It then        contact 2^(nd) level RAFS. 2^(nd) level RAFS find the match and        send back to 1^(st) RAFS. RAFS then might update its DB and send        the information to the LAFC. LAFC can update its local DB if        needed and allow running the application smoothly.    -   4. RAFS find the match however it find a policy associated with        the module that can be interpreted as “The module has expired”        or the use need to pay for the subscription. When LAFC receives        the result, deployment module in LAFC takes necessary actions.    -   5. RAFS returns the signature was not found. Deployment module        in LAFC tries to see if the module is infected by virus that        caused changing signature. It will try to scan the module for        know virus signature, if found it will clean the module and try        to re-authenticate.

A set of protocols will define how client and server modules shouldcommunicate. When LAFC send a request to RAFS to authenticate a moduleM, it combines the request as <Module Signature, Algorithm used tocompute signature, Userinfo>. When RAFS search the DB it must make surethat the algorithm used to compute signature on both end are the same.Protocol will define how initial state of DB in LAFC can be initializedand can be synced up with the global DB. Protocol will define how datafrom server client can be interpreted by participating trusted party.Communication between LAFC and RAFS must be very secure and some datacan be encrypted defined by the protocol.

Interconnected RAFS with global database (DB) components will constituteglobal Authentication framework. The global DB will be populated withmodule information from trusted source. A single DB or multiple DB willbe managed by different RAFS. RAFS in private network or individual LAFCwill know the location of those global RAFS if available. DB willcontain few tables; Tgm for module information and Tgp for policyassociated with modules. Each entry in Tgm will be populated extractinginformation from instruction module. Record of Tg will be something like<Module Signature, Module Name, Vendor Info, Creation Date, PolicyIDnumber>. Module signature will be calculated using some algorithm A(i)supported by the AF. When LAFC send some request to RAFS the requestcontains how the module signature was computed so that RAFS understandhow to match the signature. A different process can update the DB whennew instruction module is available.

It's possible that in some environment Remote Authentication Server isnot there or its DB it totally empty. Or it's possible to have a networkwithout any remote authentication server. A framework component canconnect with other framework component to share information and sometimes act as master framework component playing a role of Remoteauthentication server. Or the whole framework might be just a simplesystem without any interaction with other framework components at home.

With a single system framework, it might take some input from its userto educate itself. For example, it might ask user to provide actualsource of all installed software. Then it can scan those sources togather intelligence and build a safe rating table for safe programmodule. Or it can use the current system as a checkpoint and use allexisting program module as trusted. User can check point systemimmediately after buying the system or building a new system then checkpoint every time user upgrade system with software from trusted sources.This way framework can scan the system after every check point andcollect necessary information. Framework might ask user to set initialpolicy rules which can be as simple as “don't allow loading any newprogram module on this system” or “don't allow any program module orupdate operation to change any binary files on my system” or “don't copya new binary in my system”

When user browse internet, browser might try to install a new component.Interceptor will catch the operation that browser it trying to copy abinary file. Authentication framework will see that the new module isnot know and then policy component will see that there is a rule set byuser “don't allow a new binary to be copied into the system” and simplydeny such operation. Same way when a malicious virus tries to changesome binary in the system it would be blocked.

In a network environment, framework can learns from the activities inother framework components with very minimal input from user. Forexample when a framework sees a new module, it can communicate withother framework component to figure out if other framework componentknows such module as safe module. If other framework component certifiesthat the module is good, framework will allow loading the module andstill provide secure environment where user need not to add any input oneach system.

What has been described above includes example of the present invention.It is not possible to describe every conceivable combination ofcomponents or methodologies for purpose of describing the presentinvention. However someone with some general skill in the art may findsome combination steps, components or methodologies to implement themain theme of the present invention to achieve the same goal.

Accordingly, the present invention is intended to embrace all suchalternations, modifications and variations that fall within the spiritand aspect of the appended claims.

1. A safe program execution framework, the framework comprising: a) acall intercept processor to inspect or intercept what program or datamodule is getting loaded or already loaded in a process or what APIs aregoing to be called, b) a policy component with a set of rules and meansto enforce those rules to allow or block operations, c) anauthentication framework to gather intelligence about program modules,API call sequence or data being used across network, thus achieving asecure and safe program execution environment.
 2. A safe programexecution framework as recited in claim 1 further comprises a collectionof systems each running framework component and interact with eachother.
 3. A safe program execution framework as recited in claim 1further comprises: a) one rating table that contains different ratingsof program module that can be used to evaluate some program module, b) apolicy table to contain set of rules that can be applied on programmodules.
 4. Program or data module as recited in claim 1 referrer to anyprogram files like files with EXE DLL OCX extension or program scriptfiles that can be used to run program or any data for example a tablefrom data base or record that can be used or processed in a program. 5.Collection of systems as recited in claim 2 will share information orrate information to build intelligence what is safe to use and not safeto use.
 6. Collection of systems as recited in claim 2 will rate someinformation with low rating if smaller number of member of thecollection is exposed to it for a smaller time and will rate informationwith a higher rating when many members are using the information for anextended period without any problem.
 7. A call intercept processor asrecited in claim 1 determines what program module is going to be loadedor already loaded in a process comprises: a) active intercept processorthat intercept program module load before any computer instruction ordata in that module get a chance to be executed or being referenced inthe process b) passive inspect processor to inspect a process formodules already loaded by inspecting some process data structure orusing some OS supported functions.
 8. Call intercept processor asrecited in claim 1 will construct a unique ToBeValidated ID byextracting one or multiple module attributes like hash value of modulecontent, checksum/signature in the header, File attributes of the modulefile, pattern of API call sequence data content, or any info that can beused to identify them uniquely.
 9. Call intercept processor as recitedin claim 1 further forms ToBeValidated Module record using the moduleversion info or combining Module ID with some system attributes likeuser account info, CPU ID, machine info etc.
 10. A safe programexecution framework as recited in claim 1 will collect intelligence bycontacting other framework component across the network or by contactinga master framework component.
 11. Master framework component as recitedin claim 10 is connected with multiple framework components and exchangeinformation and rate them if some information is new, how information isbeing used, if they are safe or unsafe.
 12. A safe program executionframework as recited in claim 1 will create rules for policy componentbased on gathered intelligence and some other rules in the policycomponent or taking some feedback from end users.
 13. A safe programexecution framework as recited in claim 1 will create a rule to denyloading a program module if the module is new or is not recognized byother framework components, or user feedback doesn't allow loading themodule thus giving a low rating to the module.
 14. A safe programexecution framework as recited in claim 1 will create a rule to allowloading a program module if the module is from an established knownsource, or is being using used by other framework components forextended period of time without issues thus giving a high rating to theprogram module.
 15. A safe program execution framework as recited inclaim 1 will create a rule to rate any kind of information used in thenetwork used on its uses response and create safe rule for the system16. A safe program execution framework as recited in claim 1 Comprising:a) a local client module that try to get a rating for ToBeValidatedmodule ID using information stored in a local rating table, if can't beresolved using local rating table contact master framework component ifavailable. b) b local or master framework component that can get orgenerate rating for any ToBeValidated module ID using local rating tableaccessible to the framework component or by contacting other frameworkcomponents.
 17. Policy component as recited in claim 1, will block anyprogram module from loading or block any operation if a policy record(s)stored in policy table identify the module information as unsafe withlow rating.
 18. Policy record as recited in claim 17 will containsinformation about program module or API call sequence containing atleast one of the following: a) the module shouldn't be loaded. b) modulecan be loaded disabling some features, c) module should be replaced withanother module. d) renew license of the module. e) unsecured attempt toexecute, terminate the process. f) module uses set to expire at sometime. g) any actionable item on module or process.
 19. A safe programexecution framework as recited in claim 1 will have an update methodthat can update local rating or policy table gathering information fromother framework components.
 20. Rating table as recited in 3 willcontain information of known code segments and related licensing policyor their update information.
 21. Master framework component as recitedin claim 10 will update rating and policy table in other frameworkcomponents guided by a schedule.
 22. A safe program execution frameworkas recited in claim 1 contains multiple master framework componentsinteracting with each other to update their rating and policy table andconnecting to a top level master of master framework component wherethey altogether form a larger simplified safe execution framework.
 23. Asafe program execution framework as recited in claim 1 further comprisesa method and means to set policy and enforce it to achieve one ormultiple of the followings: a) report the administrator throughavailable reporting mechanism. b) terminate the program or disablecertain feature in the current program. c) in case of license violation,renew the feature that has the segment. d) update the program module ifnecessary. e) renew or initiate subscription of a feature is necessary.f) any helpful action/logging action that might help system user in anyway.